home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / The World of Computer Software.iso / vl6-4.zip / VL6-4.TXT < prev   
Internet Message Format  |  1993-01-15  |  40KB

  1. From lehigh.edu!virus-l Sat Jan  9 03:08:20 1993
  2. Date: Wed, 6 Jan 1993 16:29:05 -0500
  3. Message-Id: <9301062041.AA14693@barnabas.cert.org>
  4. Comment: Virus Discussion List
  5. Originator: virus-l@lehigh.edu
  6. Errors-To: krvw@cert.org
  7. Reply-To: <virus-l@lehigh.edu>
  8. Sender: virus-l@lehigh.edu
  9. Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
  10. From: "Kenneth R. van Wyk" <krvw@cert.org>
  11. To:   Multiple recipients of list <virus-l@lehigh.edu>
  12. Subject: VIRUS-L Digest V6 #4
  13. Status: R
  14.  
  15. VIRUS-L Digest   Wednesday,  6 Jan 1993    Volume 6 : Issue 4
  16.  
  17. Today's Topics:
  18.  
  19. Re: os2-stuff (OS/2)
  20. Re: Viruses in OS/2 HPFS (OS/2)
  21. Info on Music Bug virus (PC)
  22. Re: Vshield vs Virstop (PC)
  23. Jerusalem (Israeli) Virus (PC)
  24. Re: Brain Viruses (PC)
  25. Info on 1575 Virus Needed (PC)
  26. Is this VIRSTOP version current? (PC)
  27. Yet another undocumented MS-DOS 5.00 FDISK "Feature" (PC)
  28. Re: NEW MPC On the way (PC)
  29. Re: SUMMARY: FORM virus infection in Germany (PC)
  30. Re: Virus Simulator MtE Suppliment (PC)
  31. Clash between FDISK/MBR and scanners (PC)
  32. Re: MS-DOS CHKDSK & VER /R (PC)
  33. Re: Is this a new virus? (PC)
  34. McAfee libel suit (From Risks-l Digest...)
  35. Interesting Book
  36. Re: Viral Based Distribution System
  37. Changes at ASP
  38. On the definition of viruses
  39. Call for Papers - National Computer Security Conference
  40.  
  41. VIRUS-L is a moderated, digested mail forum for discussing computer
  42. virus issues; comp.virus is a non-digested Usenet counterpart.
  43. Discussions are not limited to any one hardware/software platform -
  44. diversity is welcomed.  Contributions should be relevant, concise,
  45. polite, etc.  (The complete set of posting guidelines is available by
  46. FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with
  47. your real name.  Send contributions to VIRUS-L@LEHIGH.EDU.
  48. Information on accessing anti-virus, documentation, and back-issue
  49. archives is distributed periodically on the list.  A FAQ (Frequently
  50. Asked Questions) document and all of the back-issues are available by
  51. anonymous FTP on cert.org (192.88.209.5).  Administrative mail
  52. (comments, suggestions, and so forth) should be sent to me at:
  53. <krvw@CERT.ORG>.
  54.  
  55.    Ken van Wyk
  56.  
  57. ----------------------------------------------------------------------
  58.  
  59. Date:    05 Jan 93 22:25:57 +0000
  60. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  61. Subject: Re: os2-stuff (OS/2)
  62.  
  63. KARGRA@GBA930.ZAMG.AC.AT writes:
  64.  
  65. > as pointed out in point 10 at least *.dll and *.drv files contain code which
  66. > cannot be executed by the user, but is loaded and executed as any other *.ov?
  67. > As there are viruses which infect overlays, they can be infected in a similar
  68. > way.
  69.  
  70. Could somebody check how exactly the DLL and DRV files are loaded in
  71. OS/2? The only reason that "some viruses can infect overlays" is that
  72. they infect on INT 21h/AH=4Bh, instead of INT 21h/AX=4B00h. Since some
  73. overlays are loaded with INT 21h/AX=4B03h, a sloppy written virus
  74. could infect them by mistake. How are the DLL and DRV files loaded in
  75. OS/2? If they are not loaded using any INT 21h/AX=4Bxxh function, then
  76. it is rather unlikely that any of the currently known viruses will
  77. infect them...
  78.  
  79. Regards,
  80. Vesselin
  81. - --
  82. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  83. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  84. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  85. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  86.  
  87. ------------------------------
  88.  
  89. Date:    05 Jan 93 22:50:52 +0000
  90. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  91. Subject: Re: Viruses in OS/2 HPFS (OS/2)
  92.  
  93. buhr@umanitoba.ca (Kevin Andrew Buhr) writes:
  94.  
  95. > For one thing, if a boot sector virus infects your system on start up,
  96. > it won't survive the OS/2 startup process.  You may get the "Your
  97. > computer is stoned!" message, since this is displayed (randomly
  98. > approximately one out of every eight times in many cases) before the
  99. > operating system is loaded.  HOWEVER, OS/2's own floppy disk device
  100.  
  101. A minor nit picking - Stoned displays the message only when you are
  102. booting from a floppy. It is unlikely that OS/2 will be often booted
  103. from a floppy...
  104.  
  105. > In summary, the worst you can expect is your system simply not
  106. > working.  An infected OS/2 system generally won't infect new floppy
  107. > disks unless you use the special "DOS from Drive A" sessions with an
  108. > infected boot floppy.
  109.  
  110. There is one more danger. If the virus is Michelangelo (which -is- a
  111. Stoned-like virus; it is even a Stoned variant) and the current date
  112. is March 6 - bye, bye hard disk, regardless of the operating system
  113. installed on it... :-)
  114.  
  115. Regards,
  116. Vesselin
  117. - --
  118. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  119. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  120. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  121. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  122.  
  123. ------------------------------
  124.  
  125. Date:    29 Dec 92 00:40:00 +0000
  126. From:    bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
  127. Subject: Info on Music Bug virus (PC)
  128.  
  129. Quoting from Scott Jeffrey B to All About Info on Music Bug virus ( on
  130. 12-09-92
  131.  
  132. SJ> My 286 clone was recently infected with the 'Music Bug' virus.
  133. SJ> Every time something was read from the hard disk, it played
  134. SJ> a random tune.  Didn't seem to be harmful - just annoying as hell.
  135.  
  136. The Music Bug virus isn't generally destructive, but the FAT table
  137. structure on hard drives gives some weird effects occasionally.
  138.  
  139. SJ> I'm just curious.  Does anyone know exactly what this virus does?
  140. SJ> Is it harmful?  Might I still have problems in the future as a result
  141. SJ> of this virus?
  142.  
  143. Like all boot sector viruses. if you didn't scan every diskette in the
  144. building, the virus will probably come back sooner or later.
  145.  
  146. I have heard that Music Bug waits four months before the musical effects
  147. start.
  148.  
  149. The tune is usually 36 notes long.
  150.  
  151. Bill
  152.  
  153. - ---
  154.  * WinQwk 2.0 a#383 * Thunder Byte USA BBS (615) 442-2833
  155.  
  156. ------------------------------
  157.  
  158. Date:    29 Dec 92 00:28:00 +0000
  159. From:    bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
  160. Subject: Re: Vshield vs Virstop (PC)
  161.  
  162. Quoting from Vesselin Bontchev to All About Re: Vshield vs Virstop (P on
  163. 12-09-92
  164.  
  165. VB> BTW, I think that there is a way to tell Vshield to use the EMS if yo
  166. VB> have some. This is a feature that Virstop doesn't have yet. Vshield
  167.  
  168. Vesselin:
  169.  
  170. Vshield doesn;t go into EMS. It can be loaded high in upper memory blocks.
  171. However. this is done with the /LH parameter. Vshiels will not work if
  172. users use LOADHIGH from DOS 5.0 or LOADHI in QEMM or some other memory
  173. manager.
  174.  
  175. VB> has also some other features, like an attempt to do on-line integrity
  176. VB> checking, but this is not implemented well enough.
  177.  
  178. There are several problems with the integrity checking by Scan, and
  179. Vshield.
  180.  
  181. 1. Some programs will not run after the CRC is added to the file. So it is
  182.    necessary to remove the CRC. Scan filename /RV will remove the CRC.
  183.  
  184. 2. These CRCs will not detect stealth infectors because stealth viruses
  185.    disinfects infected files when an infected file is opened for any
  186.    reason.
  187.  
  188. 3. These CRCs will not detect the presence of companion infectors because
  189.    these companion infectors do not attach to files.
  190.  
  191. Bill
  192.  
  193. - ---
  194.  * WinQwk 2.0 a#383 * JULY 13TH activates Jul 13th
  195.  
  196. ------------------------------
  197.  
  198. Date:    29 Dec 92 06:33:00 +0000
  199. From:    bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
  200. Subject: Jerusalem (Israeli) Virus (PC)
  201.  
  202. Quoting from Samid Hoda to All About Jerusalem (Israeli) Virus on 12-20-92
  203.  
  204. SH>   I need some information on the Jerusalem B virus as it has
  205. SH> infected almost every single file on my system. Does anyone know how
  206. SH> it spreads and how it spreads so fast? Any advice in getting rid of
  207. SH> the virus would be appreciated( except for a low level format as that
  208. SH> is an obvious option.)
  209.  
  210. Jerusalem B is a file infector. It runs as a TSR, and will infect every
  211. executable file you run except for .COM files larger than 62K. I believe
  212. the virus is around 1800 bytes long.
  213.  
  214. McAfee's Clean can remove this virus fairly easy to remove. It would be a
  215. very good idea to re-boot the computer from a known clean bootable
  216. diskette. If you don't have a clean bootable diskette, go ahead and type
  217. the following on the command line.
  218.  
  219. CLEAN C: [JERU]
  220.  
  221. after Clean gets finished, turn your computer off for a few seconds, then
  222. back on. The reason for this is that since Jerusalem-B runs as TSR. After
  223. the computer is clean, make a bootable diskette, then place a write
  224. protect tab on the notch. Then the next time you have another virus, you
  225. will be ready.
  226.  
  227. I hope this has been of help to you.
  228.  
  229. Bill
  230.  
  231. - ---
  232.  * WinQwk 2.0 a#383 * CASPER activates Apr 1st
  233.  
  234. ------------------------------
  235.  
  236. Date:    28 Dec 92 23:53:00 +0000
  237. From:    bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
  238. Subject: Re: Brain Viruses (PC)
  239.  
  240. Quoting from Kevin Marcus to All About Re: Brain Viruses (PC) on 12-07-92
  241.  
  242. KM> brain, whatever you wanna call it).  It is a VERY old boot sector
  243. KM> infector (some of the newer varients can infect the MBR).  This means
  244. KM> they infect disks, and not files.  It uses some steath techniques, so
  245. KM> that it hides the it's infection by redirecting calls to read in the
  246.  
  247. I'f I not mistaken. I believe "Pakistani Brain" was the first virus that
  248. used stealth routines.
  249.  
  250. No-Int (sometimes called Stoned three) is also a stealth boot sector
  251. virus. However; the stealth routines are quite sophisticated.
  252.  
  253. Bill
  254.  
  255. - ---
  256.  * WinQwk 2.0 a#383 * SATURDAY THE 14TH activates Saturday 14th
  257.  
  258. ------------------------------
  259.  
  260. Date:    Thu, 31 Dec 92 23:31:28 +0000
  261. From:    Mark Kovarski <kovarski@zooid.guild.org>
  262. Subject: Info on 1575 Virus Needed (PC)
  263.  
  264. Since I do not have FTP access intil early 1993, can someone provide
  265. me information on the 1575 Virus. I remember seeing a Database which
  266. is maintained by a german University that had great technical
  267. information about every Virus. Could someone copy the portion about
  268. the 1575 Virus and post it here. Also, what anti-virus programs can
  269. detect it and remove it? I would *GREATLY* appreciate it.
  270.  
  271. Sincerely,
  272. Mark K.
  273. Happy New Year to All.
  274. E-Mail: kovarski@zooid.guild.org
  275.  
  276. ------------------------------
  277.  
  278. Date:    Tue, 05 Jan 93 11:15:39 -0500
  279. From:    sgr4211@ggr.co.uk
  280. Subject: Is this VIRSTOP version current? (PC)
  281.  
  282. Just noticed that the version of VIRSTOP that came with F-Prot 2.06a
  283. announces itself as v2.05 on loading.  Only noticed this after 1st Jan
  284. when it complained about being old.
  285.  
  286. Is there a newer version?
  287.  
  288. Steve Richards.
  289.  
  290. ------------------------------
  291.  
  292. Date:    Tue, 05 Jan 93 13:01:14 -0500
  293. From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  294. Subject: Yet another undocumented MS-DOS 5.00 FDISK "Feature" (PC)
  295.  
  296. FDISK /STATUS (but UNFORMAT/PARTN/TEST/L is better 8*)
  297.  
  298.                Warmly,
  299.                   Padgett
  300.  
  301.  
  302. ------------------------------
  303.  
  304. Date:    05 Jan 93 18:22:37 +0000
  305. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  306. Subject: Re: NEW MPC On the way (PC)
  307.  
  308. ncoast!arnold@usenet.INS.CWRU.Edu writes:
  309.  
  310. > again about a week after the anouncement.  I have also been told that
  311. > McAFEE can already detect all the virus created with the MPC.  Note:
  312.  
  313. At least version 99 of SCAN cannot.
  314.  
  315. > There is a new Mutation Engine out called TPE, it E It is from Italy
  316. > or Somewhere near in, and supposedly it is better an MTE.  I don't
  317.  
  318. TPE seems to be from the Netherlands, according to my information...
  319. There is already at least one virus that uses it; we are calling it
  320. Girafe. TPE is smaller than MtE - about 1.6 Kb, compared to the 2.5 Kb
  321. of MtE. At first look it seems indeed more polymorphic, because there
  322. are no fixed things like JNZ backwards as in the decryptors generated
  323. by the MtE. However, if you take a closer look, you'll see that it is
  324. actually less polymorphic and if you ignore the noise instructions in
  325. the decryptor, the total number of possible decryptors seems to be
  326. less than in MtE... Of course, further analysis is needed in order to
  327. confirm that.
  328.  
  329. Regards,
  330. Vesselin
  331. - --
  332. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  333. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  334. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  335. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  336.  
  337. ------------------------------
  338.  
  339. Date:    05 Jan 93 18:30:02 +0000
  340. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  341. Subject: Re: SUMMARY: FORM virus infection in Germany (PC)
  342.  
  343. cfsc-hga-gc-mis@augsburg-emh1.army.mil (David Hanson) writes:
  344.  
  345. > Thanks to all who wrote to tell me to use SYS.COM.  However, I don't
  346. > think that I would recommend SYS without the caveat that you may lose
  347. > some FAT information.  Areyah alludes to it in his response, and in
  348. > reality, there can be quite a bit of destruction.
  349.  
  350. Could you please elaborate -how- could SYS.COM cause destruction of
  351. some FAT information? Assuming that you are using the same DOS version
  352. your DOS partition is formatted with, of course. But even if you don't,
  353. all damage I can think about is that your DOS partition could become
  354. non-bootable  or SYS could just refuse to work (i.e., "no room...")...
  355.  
  356. Regards,
  357. Vesselin
  358. - --
  359. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  360. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  361. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  362. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  363.  
  364. ------------------------------
  365.  
  366. Date:    05 Jan 93 18:39:30 +0000
  367. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  368. Subject: Re: Virus Simulator MtE Suppliment (PC)
  369.  
  370. as194@cleveland.Freenet.Edu (Doren Rosenthal) writes:
  371.  
  372. >  Thank  you for your comments on my Virus Simulator MtE Supplement. I'll  be
  373. >  mailing  the first copies january 1, so I hope your opinion  is  mistakenly
  374. >  based  on  my original Virus Simulator and not your technical review  of  a
  375. >  program you could not possibly have examined yet. Readers of this forum may
  376. >  recall  the  considerable  controversy and  strong  opinion  you  expressed
  377. >  beginning two weeks before my release of that program as well.
  378.  
  379. Well, Frisk's comments about your Virus Simulator turned out to be
  380. right even after it appeared, so I would guess that he understands the
  381. principles behind such "test" tools even better than you do...
  382.  
  383. >  pattern  to avoid recognition. A few examples of viruses that  employ  this
  384. >  same MtE engine are:
  385. >
  386. >  Pogue,  Dame, MtE, Gotcha, 7S, Mut, Dedicated, Fear, Groove,  Coffee  Shop,
  387. >  MtE-Spawn, Questo, Crypto Lab, Encroach.
  388.  
  389. Corrections: By "7S" you probably mean "Seventh_Son" ("7S" is how SCAN
  390. calls it) and it is NOT based on MtE. "Dame" is not a virus, it is
  391. just how SCAN call -all- MtE-based viruses. Gotcha is NOT an MtE-based
  392. virus. Dunno what you are calling "Mut" but I know about no such
  393. MtE-based virus. The CARO name for "MtE-Spawn" is "Insufficient". The
  394. correct spelling of the last two names is "CryptLab" and "Encroacher".
  395. "MtE" is not a virus; it is a tool for building polymorphic viruses.
  396.  
  397. When looking at the names you quoted, I am getting the impression that
  398. you knowledge about the names of the existing MtE-based viruses is
  399. based on the reports generated by SCAN, since it sometimes reports the
  400. unencrypted variants of Pogue as "Gotcha" (which is correct - Pogue is
  401. actually a Gotcha variant with MtE polymorphism added), and one of the
  402. older versions of SCAN reported "7S" in some unencrypted variants of
  403. one of the other MtE-based viruses (not certain about that; have to
  404. check).
  405.  
  406. >  Although  the  MtE  simulations  produced  by  my  program  are  safe   and
  407. >  controlled, they are real viruses, capable of infecting their special dummy
  408. >  host  programs.
  409.  
  410. So, you are not only distributing malicious software (MtE) but also
  411. real viruses, hmm? Anyway, Frisk's comment is still valid. The ability
  412. of a scanner to detect "your" viruses may or may not be related to its
  413. ability to detect -real- MtE-based viruses.
  414.  
  415. > Vigilant anti-virus programs that are capable  of  reliably
  416. >  detecting the MtE mutation engine should report these simulations as  being
  417. >  infected.
  418.  
  419. Usually, yes, but not necessarily. It depends on how your viruses
  420. infect their victims, how often they are generating unencrypted
  421. replicants, how exactly the particular scanner works, and so on. As I
  422. said, it may or it may not be connected with the actual ability of the
  423. scanner to detect the existing MtE-based viruses... But if a scanner
  424. - -doesn't- detect some of "your" viruses, this is a serious reason for
  425. further investigation. It does not necessarily mean that that
  426. particular scanner will also miss a real MtE-based virus, but it is
  427. worth checking why it misses your virus...
  428.  
  429. Regards,
  430. Vesselin
  431. - --
  432. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  433. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  434. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  435. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  436.  
  437. ------------------------------
  438.  
  439. Date:    Tue, 05 Jan 93 15:31:08 -0500
  440. From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  441. Subject: Clash between FDISK/MBR and scanners (PC)
  442.  
  443. >From:    "Roger Riordan" <riordan@tmxmelb.mhs.oz.au>
  444.  
  445. >The command FDISK /MBR is often recommended for removing MBR
  446. >infectors (Stoned, etc) from hard disks.  However in some
  447. >circumstances this can cause problems with some scanners.  It
  448. >appears that some versions of FDISK/MBR rewrite the Master Boot
  449. >Record only as far as the end of the error messages, leaving the all
  450. >important partition information unchanged, but also leaving any
  451. >viral code between the messages and the partition information.
  452.  
  453. Cannot speak for all versions but the FDISK.EXE in MS-DOS 5.00
  454. dated 3-22-91 is identical to that of 11-11-91 and both zero out all
  455. the unused bytes between the end of the messages at absolute offset
  456. 0D9h and the beginning of the partition table at offset 1BEh.
  457.  
  458. Of course FDISK/MBR will not have *any* effect with any DOS before
  459. 5.00 so this may be the cause.
  460.  
  461. It is possible that PC-DOS or some other proprietary version or even
  462. that there may be an "export" MS-DOS that might have the effect Roger
  463. reports. (can only speak for what I have seen).
  464.  
  465. Please reply directly & I will summarize any verifiable exceptions.
  466.  
  467.                Warmly,
  468.  
  469.                   Padgett
  470.       <padgett@tccslr.dnet.mmc.com>
  471.  
  472. ps anyone know what the FORMAT switches /SELECT, /BACKUP, & /AUTOTEST
  473.    do (MS-DOS 5.0) ?
  474.  
  475. ------------------------------
  476.  
  477. Date:    Tue, 05 Jan 93 15:50:52 -0500
  478. From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  479. Subject: Re: MS-DOS CHKDSK & VER /R (PC)
  480.  
  481. From:    bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
  482.  
  483. >Quoting from A. Padgett Peterson to All About MS-DOS CHKDSK & why VER / on
  484. >12-20-92
  485.  
  486. AP> Further, COMP finds no difference between this COMMAND.COM and the on
  487. AP> just expanded from a new set of distribution disks that is dated 11-1
  488.  
  489. >Just for your information, FC (File Compare) does a better job at
  490. >comparing files than COMP.
  491.  
  492. Agree that FC produces a nicer (and unlimited length) output than COMP
  493. but it was designed to compare text files and you have to remember to
  494. use the /B switch on binaries or the check may terminate on the first
  495. <EOF> marker. COMP, on the other hand, uses no intelligence, is much
  496. faster, and has worked the same way in all DOS versions. I prefer COMP
  497. when all that matters is "are the files identical?".
  498.  
  499. To each his/her/its own.
  500.  
  501.                   Warmly,
  502.                      Padgett
  503.  
  504.  
  505. ------------------------------
  506.  
  507. Date:    05 Jan 93 22:18:57 +0000
  508. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  509. Subject: Re: Is this a new virus? (PC)
  510.  
  511. tck@bend.ucsd.edu (Kevin Marcus) writes:
  512.  
  513. > >0,0,8. This is irrelevant. What is rellevant is that the problem with
  514. > >Michelangelo occurs exactly because the "standard" Stoned variant put
  515. > >the original MBR at 0,0,7 - at the same place as Michelangelo, and
  516. > >because the two viruses do not recognize each other.
  517.  
  518. > Oh, come on, it is relevant.  The original problem: Disinfection of a
  519. > Stoned and MIchelangelo infection.  Where they move the orig. MBR is
  520. > quite important, because in one case, it is possible to remove the
  521. > viruses by pulling the original MBR up, and in the other, it is not.
  522.  
  523. That's exactly what I am trying to tell you, but maybe I am not
  524. expressing myself clearly enough. The Stoned+Michelangelo problem
  525. occurs exactly because both viruses store the original MBR at ONE AND
  526. THE SAME PLACE, therefore the original MBR gets lost. Such system
  527. cannot be disinfected, because there is no original MBR. The only
  528. solution is to put a new MBR, which the anti-virus program must carry
  529. with itself. Of course, some care should be taken not to destroy any
  530. PARTITION TABLE information.
  531.  
  532. Regards,
  533. Vesselin
  534. - --
  535. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  536. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  537. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  538. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  539.  
  540. ------------------------------
  541.  
  542. Date:    Thu, 31 Dec 92 16:43:39 -0500
  543. From:    HAYES@urvax.urich.edu
  544. Subject: McAfee libel suit (From Risks-l Digest...)
  545.  
  546. Hi.
  547.  
  548. Following is a cross-post from risks-l digest.  Does anyone know more
  549. about what exactly happened?  And are they (if any) any legal problems
  550. for the end users?
  551.  
  552. BTW, found nothing in the local paper <sigh>...
  553.  
  554. In any cases....  Happy New Year to all!
  555.  
  556. Claude.
  557.  
  558. - ------  begin forwarded message ---
  559.  
  560. RISKS-LIST: RISKS-FORUM Digest  Thurs 31 December 1992  Volume 14 : Issue 20
  561.  
  562.         FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
  563.    ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
  564.  
  565. Date: Thu, 31 Dec 92 11:31:38 PST
  566. From: Peter G. Neumann <neumann@csl.sri.com>
  567. Subject: Antiviral technology target of legal action
  568.  
  569. The Washington Post has an article by John Burgess (at least some of
  570. which appears in today's San Francisco Chronicle) discussing a federal
  571. judge's order to McAfee Associates of Santa Clara CA, to stop
  572. distributing their Pro-Scan Version 2.31 and ViruCide Version 2.33 and
  573. derivative products.  Imageline Inc. of Richmond VA (maker of
  574. PicturePak and ValuePak) has sued McAfee Associates for libel, fraud,
  575. and other misdeeds, because those antiviral products mistakenly
  576. identify Imageline products as containing viruses.  Stay tuned for
  577. further details.
  578.  
  579. - ----- end forwarded message ---
  580.  
  581. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  582. Claude Bersano-Hayes     HAYES @ URVAX                 (Vanilla BITNET)
  583. University of Richmond   hayes@urvax.urich.edu     (Bitnet or Internet)
  584. Richmond, VA  23173
  585.  
  586. ------------------------------
  587.  
  588. Date:    Tue, 05 Jan 93 10:54:00 -0500
  589. From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  590. Subject: Interesting Book
  591.  
  592. Over the holidays took a much-needed rest (family went to visit
  593. cousins in Scotland & I was permitted to stay home 8*) & caught up on
  594. some reading. One of the more interesting ones was *War in 2020* by
  595. Ralph Peters.
  596.  
  597. Published in March of 1991 it missed the breakup of the Soviet Union
  598. though the afterward makes it clear that the author was not surprised.
  599.  
  600. An interesting sub-plot developed late in the book was that high-tech
  601. weaponry takes humans out of the tactical loop and relegates them to
  602. strategic decisions. Further, if you can remove trust in the weapons
  603. (virus etc.) you can destroy an adversary's capability to defend
  604. himself.
  605.  
  606. Somewhere in the last few years we seem to have lost Heinlein's "tell
  607. me three times" concept for trust and IMHO much of our difficulties
  608. today stem from this.
  609.                Philosophically,
  610.  
  611.                      Padgett
  612.  
  613. ps In a modern PC disk information is stored in the CMOS, Partition Table
  614.    and the DOS Boot Record. The code is trivial and given any two, the
  615.    third can be easily reconstructed.
  616.  
  617. ------------------------------
  618.  
  619. Date:    05 Jan 93 22:40:49 +0000
  620. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  621. Subject: Re: Viral Based Distribution System
  622.  
  623. ygoland@edison.SEAS.UCLA.EDU (The Jester) writes:
  624.  
  625. > Yes.. I understand. And may I say I STRONGLY disagree with Dr.
  626. > Cohen's definition.
  627.  
  628. Any human-language definition will be inexact. For an exact definition
  629. you should check his mathematical definition that involves Turing
  630. machines... I think it is explained in his paper "Computational
  631. Aspects of Computer Viruses", published in "Computers & Security". It
  632. is also explained in his Ph.D. thesis (although the paper is better)
  633. and is mentioned (without any explanation, which is rather confusing)
  634. in his booklet "A Short Course on Computer Viruses".
  635.  
  636. > A program in the login script that checks if you
  637. > have been updated and then updates you is NOT a virus. The program in
  638. > the loader does NOT reproduce itself it reproduces another program
  639. > which is itself NOT a virus.
  640.  
  641. No, you still do not understand. The "virus" is not just the login
  642. script - it is the whole package. The login script is just the active
  643. segment that seeks for "infectable" machines and transfers the rest of
  644. the "virus code". It is actually a worm, but Cohen's definition does
  645. not seem to make a difference between a virus and a worm.
  646.  
  647. > loader installs an infected program =) For me the acid test of a virus
  648. > is:Can it reproduce itself?
  649.  
  650. Correct. So, the copy of the anti-virus package on the server
  651. reproduces itself on each workstation when this workstation tries to
  652. log in. Automatic update. Reproduction. Virus-like behavior.
  653.  
  654. > Is the login script programming trying to
  655. > run around and find other login scripts or executable files to infect?
  656.  
  657. Another misunderstanding comes from the fact that most people
  658. distinguish between a "virus" (i.e., something that modifies
  659. executable files) and a "worm" (i.e., something that copies itself as
  660. a whole). While it is useful to make such a distinguishment for
  661. practical reasons, there is no real theoretical difference (e.g., what
  662. "files" do the boot sector viruses infect? How about the companion
  663. viruses? They do not modify anything...).
  664.  
  665. > No. It doesn't infect anyone! 'Damnit Jim, its not alive!'
  666.  
  667. Yup, it does. It "infects" the workstation with a copy of the
  668. "virus/worm" - the anti-virus package.
  669.  
  670. Regards,
  671. Vesselin
  672. - --
  673. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  674. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  675. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  676. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  677.  
  678. ------------------------------
  679.  
  680. Date:    Mon, 04 Jan 93 22:09:50 -0500
  681. From:    fc@turing.duq.edu (Fred Cohen)
  682. Subject: Changes at ASP
  683.  
  684.    As of Jan.  1, 1993, ASP has decided to transfer all
  685. maintenance, marketing, and other responsibility for all information
  686. protection products currently made and marketed by ASP to outside
  687. companies in which we have no financial interest.  We are therefore no
  688. longer involved in the commercial aspects of protection software,
  689. except for the licensing of basic technology developed at ASP.
  690.  
  691.    This transfer is being done in order to eliminate any
  692. appearance of conflicts of interest with a new venture just started as
  693. a joint project between Information Integrity and ASP - called:
  694.  
  695.               (tm)
  696.       "Protection Experts   "
  697.  
  698.           (tm)
  699.    Protection Experts   provides immediate and unbiased answers to
  700. your most pressing questions about computer security policies and
  701. practices, electronic eavesdropping and countermeasures, malicious
  702. software, network protection, and protection products and services.
  703.  
  704.    We rapidly identify, retrieve, and distribute relevant
  705. documents and information from our extensive collection of books,
  706. conference proceedings, government publications, on-line information
  707. services, journals, popular media, and product literature.
  708.  
  709.                   (tm)
  710.    For further details on Protection Experts,   please contact
  711. us at:
  712.  
  713.    8:30AM-2PM Eastern      2PM-8PM Eastern
  714.    TEL:US 412-422-4134     TEL:US 907-344-5164
  715.  
  716.    FAX:US 412-422-4135     FAX:US 907-344-3069
  717.  
  718.                Dr. Frederick B. Cohen
  719.                President ASP
  720.  
  721. ------------------------------
  722.  
  723. Date:    Tue, 05 Jan 93 22:30:03 -0500
  724. From:    fc@turing.duq.edu (Fred Cohen)
  725. Subject: On the definition of viruses
  726.  
  727.    Computer viruses do not have to be malicious, they do not have
  728. to be Trojan horses, and they do not have to enter without the
  729. knowledge or consent of the user.  Any definition that depends on
  730. these properties depends on peoples' opinions, skills, and knowledge,
  731. and are thus not "testable" in the scientific sense of the word.  (See
  732. Popper and others for more details).  For example:
  733.  
  734.    The "stoned" virus is not apparently malicious - perhaps
  735. others do not agree - perhaps this is why we should not make our
  736. definition depend on that property (i.e. peoples' opinions).  Is it a
  737. virus for you but not for me?
  738.  
  739.    The "Brain" virus notifies you of its presence with a
  740. copyright message displayed whenever you do a directory of an infected
  741. disk.  It doesn't fit the Trojan horse definition by my understanding
  742. if it announces itself.  Is it not a virus?
  743.  
  744.    If I know I am placing a Jerusalem virus in my computer, is it
  745. not a virus?  It entered with my knowledge and consent, thus it is not
  746. a virus by the third criterion above.  Is it a virus for you and not
  747. for me?
  748.  
  749.    The mathematical definition first published in 1985 is
  750. testable, and appears to properly differentiate viruses from
  751. non-viruses.  Perhaps someone else wishes to do a better job, but
  752. let's not make definitions that are senseless.
  753.  
  754.    So what is a computer virus? In simple terms, it is a sequence
  755. of instructions that, when interpreted in an appropriate environment,
  756. "replicates" in that at least one relica also "replicates", etc., ad
  757. infinitum.
  758.  
  759.    Want an example? A backup program replicates by making an
  760. exact copy of itself (if it does a good job) on the backup media.  In
  761. many environemnts, you can run a program from the backup media (e.g.
  762. a remote file system backup).  If you run the backup program from the
  763. backup media, and it again replicates, etc., ad-infinitum, then it is
  764. a virus! Suppose we put the backup program for DOS in an IBM
  765. mainframe? in that environment, it would probably not be a virus,
  766. because it wouldn't probably operate in the mainframe operating
  767. environment.  Thus we see the intimate link between a virus and its
  768. environment.  I don't want to waste more space here, but there is a
  769. good deal more to know and think about in applying this definition.
  770.  
  771. On benevolent viruses:
  772.  
  773.    If a virus doesn't have to be malicious, perhaps the same
  774. technology can be beneficial! When I published this idea in 1984 (in
  775. the paper that first described viruses to the scientific community),
  776. nobody commented on it, but when I published the results of 7 years of
  777. research with benevolent viruses in The Sciences, I was very publicly
  778. called a heretic.  The loudest complaints came from the academic
  779. community! It seems they are not as open minded as they claim to be.
  780. They were closely followed by the anti-virus industry, which has been
  781. using the press to make money by claiming that all viruses are bad.
  782. At least they have well understood motives.
  783.  
  784.    I don't so much mind that these people have their opinions,
  785. everyone is entitled to that.  I do mind when they force their
  786. opinions on others - for example, when they tell people to write
  787. letters to The Sciences telling them that it is wrong to publish the
  788. concept that viruses can be used for good, and when they claim that I
  789. am telling people about the possibility of benevolent viruses only to
  790. sell a product.  If that were true, I wouldn't publish my results, I
  791. would only use them for my financial advantage.  It is certainly true
  792. that the anti-virus vendors (which I am no longer one of) stand to
  793. make money by convincing people that all viruses are bad and that they
  794. are a major threat.
  795.  
  796.    Another upsetting example is the censure at the DPMA, ACM,
  797. IEEE Annual Computer Virus and Security Conference held in New York
  798. each March.  In this conference, they blank out portions of papers and
  799. provide full text only to conference attendees.  So if I publish
  800. details of benevolent virus techniques and how to make them safe, only
  801. the attendees will see the details, and the paper will look like swiss
  802. cheese.
  803.  
  804. Does the fairness doctrine apply to electronic media? Do the DPMA,
  805. IEEE, and ACM have such a lock on research in the computer field in
  806. the US that we allow their censorship to prevent us from hearing about
  807. ideas that aren't popular? Do the universities support this censorship
  808. of ideas? Do they do it for grant money in computer security? (They
  809. must be pretty hard up if the grant money in this field is enough to
  810. sway them into anything.)
  811.  
  812.    Maybe this posting is about a little bit more than just
  813. viruses.  It seems to me that censorship in all its forms leads to
  814. ignorance and all of it's evils.  To quote Maxwell Smart: "If only
  815. they could have used their power for goodness instead of evil."
  816.  
  817.    I am glad that other people who read virus-l don't rule out
  818. the possibility of benevolent viruses.  I'm sad that so many virus-l
  819. readers have been misled about the true meaning of viruses.  I'm even
  820. sadder that our university people in the US don't think that new and
  821. different ideas are good and decide to try to censure them.  I'm
  822. really glad that I no longer sell virus defenses, because I think it's
  823. a pretty shady business (except for a few good companies that tell the
  824. truth about viruses and their products).
  825.  
  826. ------------------------------
  827.  
  828. Date:    Fri, 01 Jan 93 20:53:36 -0500
  829. From:    Jack Holleran <Holleran@DOCKMASTER.NCSC.MIL>
  830. Subject: Call for Papers - National Computer Security Conference
  831.  
  832.                         CALL  FOR  PAPERS
  833.           16th NATIONAL  COMPUTER  SECURITY  CONFERENCE
  834.      Sponsored by the National Computer Security Center and
  835.        the National Institute of Standards and Technology
  836.  
  837.                         SEPTEMBER 20-23, 1993
  838.                             BALTIMORE, MD
  839.  
  840.  The National Computer Security Conference audience represents a broad
  841. range of interests drawn from government, industry, and academic
  842. communities.  Their interests include technical research topics,
  843. security applications, and management issues.  Papers may be addressed
  844. toward the entry level or skilled practitioner.  Special emphasis will
  845. be placed on papers addressing the special needs of users and creating
  846. better security for user information technology resources.
  847.  
  848. We are pleased to invite academic Professors to recommend Student
  849. papers in the application of Computer Security methodology.  Three
  850. student submissions will be selected by the Technical Committee for
  851. publication in the Conference Proceedings.  To be considered, the
  852. submission must be authored by an individual student with the
  853. assistance of their academic Professor and be recommended by their
  854. academic Professor.  Only one copy for student submission is required.
  855.  
  856.  
  857. BY FEBRUARY 8, 1993:  Send eight copies of your draft paper* or panel
  858.                       suggestions to the following address.  See author
  859.                       instructions for your submission format.
  860.  
  861.  *   Government employees or those under Government sponsorship
  862.      must so identify their papers.
  863.  
  864. Mailing Information
  865. National Computer Security Conference
  866. ATTN:  NCS Conference Secretary,  AS 11
  867. National Computer Security Center
  868. Fort George G. Meade, MD 20755-6000
  869.  
  870. BY MAY 15, 1993:  Speakers selected to participate in the conference
  871.                   will be notified when their camera-ready paper is
  872.                   due to the Conference Committee.  All referee comments
  873.                   will be forwarded to the primary author at this time.
  874.  
  875.  
  876. For additional information on submissions, please call (410) 850-0272.
  877.  
  878. Preparation Instructions for the Authors
  879.   To assist the Technical Review Committee, the following is required
  880. for all submissions:
  881.  
  882.    Page 1:  Type of submission (paper, panel, tutorial)
  883.             Title of submission
  884.             Keywords
  885.             Abstract (not to exceed 250 words)
  886.             Author(s)
  887.             Organization(s)
  888.             Phone number(s)
  889.             Net address(es), if available
  890.             Point of Contact
  891.  
  892.   Submissions having U.S.  Government sponsorship must also provide
  893. the following information:
  894.      U.S. Government Program Sponsor or Procuring Element
  895.      Contract number (if applicable)
  896.      U.S. Government Publication Release Authority
  897.    Note:  Responsibility for U.S. Government pre-publication review lies
  898.           with the author(s).
  899.  
  900.   The submission (pages 2-9, these are the 8 pages of your submission):
  901.      Title of submission - do not include author(s), address(es)
  902.                             or organization(s)
  903.      Abstract (with keywords)
  904.      The paper
  905.           (Suggested Length: 8 pages, including figures and diagrams;
  906.                       pitch:  no smaller than 8 point; 1 inch
  907.                       margins on top, bottom and sides.)
  908.  
  909. A Technical Review Committee, composed of Government and Industry Computer
  910. Security experts, will referee submissions only for technical merit for
  911. publication and presentation at the National Computer Security (NCS)
  912. Conference.  No classified submissions will be accepted for review.
  913.  
  914. The Conference Committee provides for a double "blind" refereeing.  Please
  915. place your names and organizations ONLY on page 1 of your submission, as
  916. defined above.  Failure to COMPLY with the above instructions may result in
  917. non-selection BEFORE the referee process.  Papers in excess of 8 pages may
  918. also result in non-selection BEFORE the referee process.
  919.  
  920. Papers drafted as part of the author's official U.S.  Government duties may
  921. not be subject to copyright.  Papers submitted that are subject to copyright
  922. must be accompanied by a written assignment to the NCS Conference Committee or
  923. written authorization to publish and release the paper at the Committee's
  924. discretion.  Papers selected for presentation at the NCS Conference requiring
  925. U.S.  Government pre-publication review must include, with the submission of
  926. the final paper to the committee, a written release from the U.S.  Government
  927. Department or Agency responsible for pre-publication review.  The release is
  928. required no later than July 1, 1992.  Failure to comply may result in
  929. rescinding selection for publication and for presentation at the 16th NCS
  930. Conference.
  931.  
  932. Technical questions can be addressed to the NCS Conference Committee by mail
  933. (see Mailing Information) or by phone, (410) 850-0CSC [0272].  For other
  934. information about the conference, please call (301) 975-2775.
  935.  
  936. ------------------------------
  937.  
  938. End of VIRUS-L Digest [Volume 6 Issue 4]
  939. ****************************************
  940.  
  941.  
  942.